2025年8月30日中文

利用 React 选择性水合提升网页性能。本深度指南解释了组件级水合的原理、优势，以及面向全球应用的实践策略。

掌握 Web 性能：深入剖析 React 选择性水合

在现代数字领域，速度不仅仅是一项功能；它是构成良好用户体验的基础。对于全球性的应用程序而言，用户通过各种各样的设备和网络条件访问内容，因此性能至关重要。加载缓慢的网站会导致用户失望、跳出率增高和收入损失。多年来，开发者利用服务器端渲染 (SSR) 来改善初始加载时间，但这带来了一个重大的权衡：在整个 JavaScript 包下载并执行之前，页面是不可交互的。正是在这里，React 18 引入了一个革命性的概念：选择性水合 (Selective Hydration)。

这份全面的指南将探讨选择性水合的复杂之处。我们将从 Web 渲染的基础知识讲起，一直到 React 并发功能的高级机制。您不仅会学到什么是选择性水合，还会了解它的工作原理、为什么它对核心 Web 指标 (Core Web Vitals) 是一次颠覆性的变革，以及如何在您自己的项目中实施它，从而为全球用户构建更快、更具弹性的应用程序。

React 渲染的演进：从 CSR 到 SSR 及更远

要真正领会选择性水合的创新之处，我们必须首先了解其发展历程。我们渲染网页的方式已经发生了显著的演变，每一步都旨在解决前一步的局限性。

客户端渲染 (CSR)：单页应用的兴起

在早期使用像 React 这样的库构建的单页应用 (SPA) 中，客户端渲染是标准做法。其过程很简单：

服务器发送一个极简的 HTML 文件，通常只有一个 `
` 元素，以及指向大型 JavaScript 文件的链接。
浏览器下载 JavaScript。
React 在浏览器中执行，渲染组件并构建 DOM，使页面可见并可交互。

优点：CSR 在初始加载后能实现高度交互的、类似应用的体验。页面之间的转换很快，因为不需要完整的页面重新加载。
缺点：初始加载时间可能非常缓慢。在 JavaScript 被下载、解析和执行之前，用户看到的是一片白屏。这导致了糟糕的首次内容绘制 (FCP)，并且对搜索引擎优化 (SEO) 不利，因为搜索引擎爬虫通常看到的是一个空页面。

服务器端渲染 (SSR)：拯救速度与 SEO

SSR 的引入解决了 CSR 的核心问题。通过 SSR，React 组件在服务器上被渲染成一个 HTML 字符串。这个完全成形的 HTML 随后被发送到浏览器。

浏览器接收并立即渲染 HTML，因此用户几乎可以即时看到内容（优秀的 FCP）。
搜索引擎爬虫可以有效地索引内容，提升 SEO。
在后台，相同的 JavaScript 包被下载。
下载完成后，React 在客户端运行，将事件监听器和状态附加到已有的服务器渲染的 HTML 上。这个过程被称为水合 (hydration)。

传统 SSR 的“恐怖谷”

虽然 SSR 解决了白屏问题，但它引入了一个新的、更微妙的问题。页面在真正变得可交互之前，看起来像是可交互的。这创造了一个“恐怖谷”，用户看到一个按钮，点击它，却没有任何反应。这是因为让那个按钮工作所需的 JavaScript 还没有完成对整个页面的水合工作。

这种挫败感是由整体水合 (monolithic hydration) 造成的。在 React 18 之前的版本中，水合是一个全有或全无的操作。整个应用程序必须在一次传递中完成水合。如果你有一个极其缓慢的组件（可能是一个复杂的图表或一个沉重的第三方小部件），它会阻塞整个页面的水合。你的页头、侧边栏和主要内容可能很简单，但在最慢的组件也准备好之前，它们无法变得可交互。这通常会导致糟糕的可交互时间 (TTI)，一个对用户体验至关重要的指标。

什么是水合？解析核心概念

让我们进一步明确对水合的理解。想象一个电影布景。服务器构建了静态的布景（HTML）并将其发送给你。它看起来很真实，但演员（JavaScript）还没有到场。水合就是演员们到达片场，各就各位，并通过动作和对话（事件监听器和状态）将场景带入生活的过程。

在传统的水合中，从主角到背景临时演员，每一个演员都必须就位，导演才能喊“开拍！”。如果一个演员堵车了，整个制作就得暂停。这正是选择性水合要解决的问题。

选择性水合简介：颠覆性变革

选择性水合是 React 18 在使用流式 SSR 时的默认行为，它打破了整体模型。它允许您的应用程序分块进行水合，优先处理最重要的部分或用户正在与之交互的部分。

以下是它从根本上改变游戏规则的方式：

非阻塞式水合： 如果一个组件尚未准备好水合（例如，其代码需要通过 `React.lazy` 加载），它不再阻塞页面的其余部分。React 会简单地跳过它，去水合下一个可用的组件。
使用 Suspense 进行流式 HTML： React 不会等待服务器上的慢组件，而是可以发送一个占位符（如加载指示器）来代替它。一旦慢组件准备就绪，它的 HTML 会被流式传输到客户端并无缝替换占位符。
用户优先的水合： 这是最精彩的部分。如果用户在某个组件水合之前与之交互（例如，点击一个按钮），React 会优先水合该特定组件及其父组件。它会记录该事件，并在水合完成后重放它，使应用感觉即时响应。

回到我们的商店比喻：有了选择性水合，顾客们一旦准备好就可以结账离开。更好的是，如果一个赶时间的顾客靠近收银台，店长（React）可以优先处理他们，让他们排到队伍的最前面。这种以用户为中心的方法使得体验感觉快得多。

选择性水合的支柱：Suspense 与并发渲染

选择性水合并非魔法；它是 React 中两个强大且相互关联的功能的结果：服务器端 Suspense 和并发渲染。

理解服务器上的 React Suspense

您可能熟悉在客户端使用 `` 和 `React.lazy` 进行代码分割。在服务器上，它扮演着类似但更强大的角色。当您用 `` 边界包裹一个组件时，您是在告诉 React：“这部分 UI 可能不会立即准备好。不要等它。先发送一个占位符，等它准备好后再把真实内容流式传输过来。”

考虑一个包含产品详情部分和社交媒体评论小部件的页面。评论小部件通常依赖第三方 API，可能会很慢。

```jsx // 之前：服务器等待 fetchComments() 解析，延迟了整个页面。 function ProductPage({ productId }) { const comments = fetchComments(productId); return ( <> ); } // 之后：使用 Suspense，服务器立即发送 ProductDetails。 import { Suspense } from 'react'; const Comments = React.lazy(() => import('./Comments.js')); function ProductPage() { return ( <> }> ); } ```

通过这个改变，服务器不再等待 `Comments` 组件。它会立即发送 `ProductDetails` 和 `Spinner` 占位符的 HTML。`Comments` 组件的代码在后台于客户端加载。一旦它到达，React 就会对其进行水合，并用它替换加载指示器。用户可以更快地看到并与主要产品信息进行交互。

并发渲染的角色

并发渲染是使这一切成为可能的底层引擎。它允许 React 暂停、恢复或放弃渲染工作，而不会阻塞浏览器的主线程。可以把它想象成一个用于 UI 更新的复杂任务管理器。

在水合的背景下，并发性使得 React 能够：

一旦初始 HTML 和一些 JavaScript 到达，就开始水合页面。
如果用户点击一个按钮，就暂停水合。
优先处理用户的交互，水合被点击的按钮并执行其事件处理程序。
交互处理完毕后，在后台恢复水合页面的其余部分。

这种中断机制至关重要。它确保用户输入得到立即处理，从而极大地改善了诸如首次输入延迟 (FID) 和更新、更全面的下次绘制交互 (INP) 等指标。即使页面仍在后台加载和水合，它也永远不会感觉卡顿。

实践：将选择性水合引入您的应用

理论虽好，但让我们付诸实践。您如何在自己的 React 应用中启用这个强大的功能呢？

先决条件与设置

首先，确保您的项目已正确设置：

升级到 React 18：`react` 和 `react-dom` 包都必须是 18.0.0 或更高版本。
在客户端使用 `hydrateRoot`：用新的 `hydrateRoot` API 替换旧的 `ReactDOM.hydrate`。这个新 API 会让您的应用选择加入并发功能。 ```jsx // client/index.js import { hydrateRoot } from 'react-dom/client'; import App from './App'; const container = document.getElementById('root'); hydrateRoot(container, ); ```
在服务器上使用流式 API：您必须使用一个流式渲染器。对于 Node.js 环境，如 Express 或 Next.js，这是 `renderToPipeableStream`。其他环境有其对应的 API（例如，Deno 或 Cloudflare Workers 的 `renderToReadableStream`）。

代码示例：分步指南

让我们用 Express.js 构建一个简单的例子来演示整个流程。

我们的应用结构：

一个 `App` 组件，包含一个 `` 和一个 `
` 内容区域。
一个立即可用的 `` 组件。
一个缓慢的 `` 组件，我们将对其进行代码分割和暂停。

第一步：服务器 (`server.js`)

在这里，我们使用 `renderToPipeableStream` 来分块发送 HTML。

```jsx // server.js import express from 'express'; import fs from 'fs'; import path from 'path'; import React from 'react'; import ReactDOMServer from 'react-dom/server'; import App from './src/App'; const app = express(); app.use('^/$', (req, res, next) => { const { pipe } = ReactDOMServer.renderToPipeableStream( , { bootstrapScripts: ['/main.js'], onShellReady() { res.setHeader('content-type', 'text/html'); pipe(res); } } ); }); app.use(express.static(path.resolve(__dirname, 'build'))); app.listen(3000, () => { console.log('Server is listening on port 3000'); }); ```

第二步：主应用组件 (`src/App.js`)

我们将使用 `React.lazy` 动态导入我们的 `CommentsSection` 并将其包裹在 `` 中。

```jsx // src/App.js import React, { Suspense } from 'react'; const CommentsSection = React.lazy(() => import('./CommentsSection')); const Spinner = () =>

正在加载评论...

; function App() { return (

我的精彩博文

这是主要内容。它能即时加载并立即可交互。

); } export default App; ```

第三步：慢组件 (`src/CommentsSection.js`)

为了模拟一个慢组件，我们可以创建一个简单的工具函数，它包装一个 promise 来延迟其解析。在真实场景中，这种延迟可能是由于复杂的计算、一个大的代码包或数据获取造成的。

```jsx // 一个模拟网络延迟的工具函数 function delay(ms) { return new Promise(resolve => setTimeout(resolve, ms)); } // src/CommentsSection.js import React from 'react'; // 模拟一个缓慢的模块加载 await delay(3000); function CommentsSection() { return (

好文！
信息量很大，谢谢。

); } export default CommentsSection; ```

（注意：顶层 `await` 需要现代打包工具进行相应配置。）

运行时会发生什么？

请求： 用户请求页面。
初始流： Node.js 服务器开始渲染。它渲染了 `nav`、`h1`、`p` 和 `button`。当它遇到 `CommentsSection` 的 `` 边界时，它不会等待。它发送占位符 HTML（`
正在加载评论...
`）并继续。初始的 HTML 块被发送到浏览器。
快速 FCP： 浏览器渲染这个初始 HTML。用户立即看到导航栏和主要博文内容。评论区显示加载信息。
客户端 JS 加载： `main.js` 包开始下载。
选择性水合开始： 一旦 `main.js` 到达，React 开始水合页面。它为 `nav` 和 `button` 附加事件监听器。即使用户评论仍在“加载”中，他们现在也可以点击“点我”按钮并看到弹窗。
懒加载组件到达： 在后台，浏览器获取 `CommentsSection.js` 的代码。我们模拟的 3 秒延迟发生在这里。
最终流和水合： 一旦 `CommentsSection.js` 加载完成，React 会对其进行水合，无缝地将 `Spinner` 替换为实际的评论列表和输入框。这个过程不会中断用户或阻塞主线程。

这个精细化的、有优先级的过程就是选择性水合的精髓。

分析影响：性能优势与用户体验的胜利

采用选择性水合不仅仅是追随最新潮流；它是为了给您的用户带来切实的改进。

改善核心 Web 指标

可交互时间 (TTI)： 这是改善最显著的指标。由于页面的部分内容在水合时即可交互，TTI 不再由最慢的组件决定。可见的、高优先级内容的 TTI 会提前很多达到。
首次输入延迟 (FID) / 下次绘制交互 (INP)： 这些指标衡量响应性。因为并发渲染可以中断水合来处理用户输入，用户操作与 UI 响应之间的延迟被最小化了。页面从一开始就感觉非常灵敏和响应迅速。

增强的用户体验

技术指标直接转化为更好的用户旅程。消除 SSR 的“恐怖谷”是一个巨大的胜利。用户可以相信，如果他们能看到一个元素，他们就能与之交互。对于网络较慢的全球用户来说，这是变革性的。他们不再需要等待一个几兆字节的 JavaScript 包加载完成才能使用网站。他们可以分块获得一个功能性的、可交互的界面，这是一种更优雅、更令人满意的体验。

全球化性能视角

对于服务全球客户群的公司来说，网络速度和设备能力的多样性是一个重大挑战。一个在首尔使用高端智能手机和 5G 网络的用户，与一个在农村地区使用廉价设备和 3G 网络的用户，体验会截然不同。选择性水合有助于弥合这一差距。通过流式传输 HTML 和选择性水合，您可以更快地为网络慢的用户提供价值。他们首先获得关键内容和基本交互性，而较重的组件则在后台加载。这种方法为世界各地的每个人创造了一个更公平、更易于访问的 Web。

常见陷阱与最佳实践

为了充分利用选择性水合，请考虑以下最佳实践：

识别水合瓶颈

使用 React 开发者工具的性能分析器 (Profiler) 来识别哪些组件渲染和水合的时间最长。寻找那些在客户端计算成本高、依赖树庞大或初始化了沉重的第三方脚本的组件。这些是包裹在 `` 中的首选对象。

策略性地使用 ``

不要把每个组件都用 `` 包裹起来。这可能导致碎片化的加载体验。要有策略。适合暂停的候选对象包括：

首屏以下的内容： 用户最初看不到的任何东西。
非关键小部件： 聊天机器人、详细的分析图表、社交媒体信息流。
基于用户交互的组件： 默认不可见的模态框或选项卡内的内容。
沉重的第三方库： 交互式地图或复杂的数据可视化组件。

数据获取的考量

选择性水合与支持 Suspense 的数据获取方式协同工作。虽然 React 本身不附带特定的数据获取解决方案，但像 Relay 这样的库和像 Next.js 这样的框架都有内置支持。您也可以构建自定义钩子，通过抛出一个 promise 来与 Suspense 集成，让您的组件在服务器上等待数据而不会阻塞初始流。

SEO 影响

对于高级渲染技术，一个普遍的担忧是 SEO。幸运的是，选择性水合对 SEO 非常友好。因为初始 HTML 仍然在服务器上渲染，搜索引擎爬虫能立即接收到有意义的内容。现代爬虫，如 Googlebot，也能处理 JavaScript，并能看到稍后流式传入的内容。其结果是一个快速、可索引且对用户高性能的页面——一个双赢的局面。

React 渲染的未来：服务器组件

选择性水合是一项基础技术，它为 React 的下一次重大演进铺平了道路：React 服务器组件 (RSC)。

服务器组件是一种新型组件，它只在服务器上运行。它们没有客户端 JavaScript 的足迹，这意味着它们对您的包大小贡献为零。它们非常适合显示静态内容或直接从数据库获取数据。

未来的愿景是多种架构的无缝融合：

服务器组件用于静态内容和数据访问。
客户端组件（我们今天使用的组件）用于交互性。
选择性水合作为桥梁，使页面的交互部分在不阻塞用户的情况下变得生动起来。

这种组合有望实现两全其美：服务器渲染应用的性能和简单性，以及客户端 SPA 的丰富交互性。

结论：Web 开发的范式转变

React 选择性水合不仅仅是一次渐进式的性能改进。它代表了我们构建 Web 方式的一次根本性范式转变。通过摆脱单一的、全有或全无的模型，我们现在可以构建更精细、更有弹性、并以用户实际交互为中心的应用程序。

它使我们能够优先处理重要的事情，即使在具有挑战性的网络条件下也能提供可用和愉悦的体验。它承认网页的并非所有部分都生而平等，并为开发者提供了精确编排加载过程的工具。

对于任何从事大型、全球性应用的开发者来说，升级到 React 18 并拥抱选择性水合不再是可选项——而是必需品。今天就开始尝试 `Suspense` 和流式 SSR 吧。您的用户，无论他们身在何处，都会感谢您带来的更快、更流畅、更具响应性的体验。